\documentclass[12pt]{report}
\usepackage{cite}
\usepackage{graphicx,url,verbatim,color,pstcol,pst-node,pstricks,subfigure,qtree}
\usepackage[utf8]{inputenc}
\usepackage{glossary}
\makeglossary

\title{Tecnologias de Apoio a Execução de Processos de Negócios na SPTC-ES}

\author{}

\begin{document}
\maketitle

\begin{abstract}
O Projeto Nêmesis tem como um de seus objetivos a elaboração de um Modelo de Referência para Tecnologias de Informação, Comunicação e Biometria no suporte a Polícias Técnico Científica.
Este artigo tem o intuito de apresentar tecnologias que apoiam a execução de processos de negócios.
\end{abstract}


\chapter{Introdução}

Este relatório tem como objetivo apresentar as principais tecnologias para apoio de execução de processos de negócios presentes no mercado.

O relatório está dividido da seguinte maneira:

No Capítulo 2, apresentamos Web Services, seu ciclo de vida e os principais padrões que permitem sua interoperabilidade; No Capítulo 3, explicamos um pouco sobre Arquitetura Orientada a Serviço (SOA), os principios de padrões que possibilita as empresas uma integração mais rapida e dinamica aos seus serviços; No Capítulo 4, Enterprise Service Bus, a tecnologia que fornece a estrtura basica para a implementação de um SOA; Capítulo 5,  a linguagem BPEL que possibilita modelar processos de negocios complexos e executa-los como se fossem serviços, por meio de orquestração de Web Services; Capítulo 6, BASS o framework que facilita o desenvolvimento de aplicações que utilizam Web Services; Capítulo 7, mostra um pouco da Infra-estrutura atual da Superintendência da Polícia Técnico-Científica do Espirito Santo (SPTC-ES); Capítulo 8, falamos um pouco do e-PING, padrão que define como deve ser a interação entre Poderes e esferas do governo e a sociedade em geral. No Capítulo 9 fazemos uma proposta de como os processos de negocio da SPTC deveriam ser hoje, tendo em consideração os capítulos acima. E no Capítulo 10, concluimos o relatório.

\chapter{Serviços {\it WEB}}

Serviço {\it WEB} é um sistema de {\it software} projetado para suportar interações entre maquinas em uma rede. Ele tem uma interface descrita em um formato que pode ser processado por computadores (especificamente WSDL). Outros sistemas interagem com o serviço {\it WEB} de maneira prescrita pela sua descrição usando mensagens SOAP, tipicamente transmitidas via HTTP junto com um conjunto de outros padrões web serializados em um XML \cite{w3c}.

\glossary{name={Web Services Description Language (WSDL)}, description={Linguagem baseada em XML utilizada para a descrição de um Web Service.}}
\glossary{name={Service Oriented Architecture Protocol (SOAP)}, description={Padrão para empacotamento e troca de mensagens XML.}}

Por serem construídos em cima de XML e padrões abertos, serviços {\it WEB} são interoperáveis, ou seja, qualquer cliente pode beneficiar-se desse serviço, independente de sua plataforma ou linguagem de programação utilizada.

\section{Ciclo de Vida de um Serviço {\it WEB}}

Para descrever o ciclo de vida de um web service, desde a descoberta do serviço até a troca de mensagens em si, primeiro é preciso definir alguns termos.


{\bf Agente}  é um software ou hardware que envia e recebe mensagens, uma implementação de um {\it web service}.

{\bf Entidade Provedora } é uma pessoa ou organização que prove um agente que implementa um serviço.

{\bf Entidade Requisitante} é uma pessoa ou organização que deseja usar um serviço {\it WEB} de uma Entidade Provedora.


Se uma entidade requisitante deseja interagir com uma entidade provedora, mas ainda não sabe qual serviço deseja utilizar, então a entidade requisitante irá precisar descobrir um candidato adequado. Descoberta é o ato de localizar uma interface de web service que previamente era desconhecida e que satisfaça a alguns critérios funcionais\cite{w3c}.

\begin{figure}[htbp]
	\centering
	\includegraphics[width=12.22cm, scale=1]{./imagens/descoberta.png}
	\caption{Processo de Descoberta de Serviço\label{fig:descoberta}}
\end{figure}

\glossary{name={WSD}, description={Descreve a interface de um serviço.}}
\glossary{name={FD}, description={Descreve as funcionalidades de um serviço.}}

\footnote{WSD: descrição da interface de um web service.}
\footnote{FD: descrição das funcionalidades do serviço.}

Passos do processo de descoberta de serviço:
\begin{enumerate}
	\item[1.] A entidade requisitante e a provedora se tornam “conhecidas”.
	\begin{enumerate}
		\item[a)] O serviço de descoberta obtêm o FD e o WSD dos serviços da entidade provedora.
		\item[b)] A entidade requisitante envia para o serviço de descoberto os critérios para selecionar o serviço que ela deseja. Os critérios podem ser as funcionalidades do serviço web, capacidades ou outras características. Normalmente os serviços são localizados por funcionalidades ou semânticas, mas outros critérios também podem ser utilizados como nome do provedor do serviço, performance ou confiabilidade.
		\item[c)] O serviço de descoberta retorna uma ou várias descrições de serviços. Se múltiplas descrições forem retornadas a entidade requisitante pode utilizar critérios adicionais para selecionar um serviço.
	\end{enumerate}

	\item[2.] A entidade requisitante e provedora concordam com a semântica da interação desejada.
	\item[3.] A semântica e a descrição do serviço são colocadas nos dois agentes.
	\item[4.] Por ultimo ocorre a iteração entre os agentes, por meio de troca de mensagens SOAP. Ou seja o web service encontrado é consumido.
\end{enumerate}

\section{Padrões que apoiam os serviços WEB}

\subsection{XML}
Extensible Markup Language (XML) é uma serie de regras para codificação de documentos eletronicamente. XML foi projeto com o intuito de ser simples, genérica e usável na internet. Seu formato é textuais com suporte para Unicode. É muito utilizado para representação de estruturas arbitrárias.

\subsection{WSDL}
WSDL é uma linguagem para descrição de Web services. A descrição do serviço começa com as mensagens que serão trocadas entre o agente requisitante e o provedor. As mensagens são descritas de uma forma abstratas e depois é delimitado o protocolo de transporte e o formato da mensagem.

\subsection{SOAP}
SOAP é um padrão para empacotamento e troca de mensagens XML. De acordo com o W3C, SOAP pode refletir a dois termos diferentes:
\begin{enumerate}
	\item Service Oriented Architecture Protocol: neste caso uma mensagem SOAP representa a informação necessária para invocar um serviço ou retornar os resultados de uma invocação.
	\item Simple Object Acess Protocol: a mensagem SOAP representa uma invocação a um objeto remoto (RPC) e a serialização da lista de argumentos desse método que será movida do ambiente local ao ambiente remoto.
\end{enumerate}
Apesar de existir duas definições para o SOAP, estamos interessados apenas na primeira. Por isso  SOAP  nesse documento, deve ser entendido como  Service Oriented Architecture Protocol.

\glossary{name={The World Wide Web Consortium (W3C)}, description={Comunidade internacional que desenvolve padrões para garantir o crescimento da WEB.}}

\subsection{UDDI}
É um protocolo que especifica métodos ara publicar e descobrir diretórios de serviços. Um registro UDDI é uma representação dos dados e metadados de um serviço web. Um registro para uso em uma rede publica ou dentro de uma organização oferece um mecanismo padrão para classificação, catalogação e gerenciamento dos web services. E por isso, utilizando estes mecanismos, serviços podem ser descobertos e consumidos por outras aplicações\cite{uddi}.

\glossary{name={Universal Description, Discovery and Integration (UDDI)}, description={Protocolo para publicar e descobrir Web Services em um diretório de serviços.}}

Na \ref{descoberta}, mostramos como a descoberta de um serviço pode ser feita. O serviço de descoberta mostrado na figura poderia ser uma implementação do UDDI.

\subsection{WS-Addressing}
WS-Addressing é um modo padronizado de incluir roteamento de mensagens dentro do cabeçalho SOAP.

\section{Segurança}
Um ponto fraco do web service é a segurança, mas não pela falta de padrões para segurança e sim pela falta de consenso sobre quais padrões utilizar.

Pode ser desastroso para a empresa não utilizar ou não testar corretamente a segurança de seus serviços web, principalmente quando estes serviços estão cada vez mais sendo disponibilizados via internet e ainda na porta 80\cite{vulnerabilidades}.

Algumas organizações desenvolvem e mantem perfis de segurança como a {\it National Security Agence} (NSA), que desenvolveu um perfil para segurança de SOAP, ele cobre assinatura digital, encriptografia e tokens de segurança\cite{perfil-seguranca}.

%%-- figura

\subsection{XML-Signature}
XML Signature foi projetado para uso em transações XML. É um padrão que foi desenvolvido pelo W3C e pela IETF. O padrão define um schema para captura de uma operação de assinatura digital aplicada em uma informação qualquer. XML signature prova autenticação, integridade e suporte para não ter rejeição dos dados assinados.

\subsection{XML-Encryption}
XML Encryption específica um processa para criptografia dados e representação do resultado em XML. O resultado do processo é um XML  que contem referencias para os dados criptografados.

\subsection{WS-Security}
Desenvolvido pela OASIS, Web Services Security (WSS) define uma extensão SOAP para prover proteção através de integridade, confidencialidade e autenticação da mensagem. WSS pode ser usado para acomodar uma grande variedade de modelos de segurança e tecnologias de encriptografia, exemplo XML-Signature e XML-Encryption.

\subsection{SALM}
{\it Security Assertion Markup Language}, SAML, é um padrão baseado em XML para a troca autenticada e autorizada de mensagens entre dominios seguros.

\chapter{Arquitetura Orientada a Serviços}

Arquitetura Orientada a Serviço (SOA), é um modo lógico de projetar softwares que oferecem serviços para usuários finais, aplicativos ou serviços distribuidos pela internet via interfaces publicadas que podem ser descobertas. SOA pode capacitar uma organização com uma estrutura flexivel e um ambiente de processamento que oferecem funcionalidades na forma de serviço e provendo uma fundação para a evolução desses serviços.\cite{soc}


SOA geralmente oferece uma maneira dos consumidores descobrirem serviços. Por exemplo, diversos departamento diferentes de uma companhia podem desenvolver serviços em diferentes linguagens de programação, os clientes irão se beneficiar de uma interface bem definida para acessá-los. Apesar de ser comum o uso de XML para interfacear os serviços, não é obrigatório o uso do mesmo em uma arquitetura orientada a serviços.

SOA é uma arquitetura conceitual que define que os aplicativos devem implementar suas funcionalidades de negócios na forma de serviços. Serviços são consumidos por aplicativos, os quais também podem ser implementações de serviços. Com essa abordagem processos de negócios complexos são implementados através de combinações de serviços. Isto é chamado de orquestração de serviços.



\chapter{Enterprise Service Bus (ESB)}


Enterprise Service Bus (ESB) é um termo relativamente novo na industria de softwares. Ainda não existe consenso sobre uma definição comum e existem muitas discussões sobre quais recursos devem ser inclusos e quais tecnologias devem ser utilizadas.

Enterprise Service Bus é um padrão aberto baseado em mensagens, infraestrutura de integração distribuída que oferece roteamento, invocação e mediação de serviços para facilitar interações entre aplicativos distribuídos e serviços de um modo seguro e confiável.\cite{ESB1}

%--figura

ESBs são usualmente construídos através de conteiners de serviços distribuídos em uma rede. Esses  conteiners hospedam serviços de integração como roteamento, transformação, adaptadores de aplicativos e oferecem a eles vários meios de se comunicarem. Atualmente a infraestrutura de mensagens dos ESBs normalmente são construídas no topo de um midleware baseado em JMS, que garante entrega de mensagem. Aplicativos são conectados ao barramento utilizando adaptadores de aplicativos ou um dos mecanismos de mensagem suportados. Para suportar SOA os conteiners do ESB devem suportar todos as principais tecnologias de web service. Os componentes do ESB e os mecanismo para conexão devem ser baseados em padrões abertos para garantir interoperabilidade e proteger os investimentos.

Um Enterprise Service Bus deve coordenar as interações entre os vários recursos e oferecer suporte de transação. A ideia geral é prover mensagem e integração sem escrever nenhum código.

ESBs são backbones ideais para implementação de uma arquitetura orientada a serviços porque eles oferecem um mecanismo para interconectar todos os serviços requeridos em uma solução de negocio composta, sem comprometer segurança, confiabilidade, performance e escabilidade.

ESB formaliza a maneira em que um serviço é publicado, ele faz isso fornecendo um registro dos serviços que estão disponíveis para invocação e os consumidores que irão se comunicar a eles\cite{ESB2}. O registro é acessível durante o desenvolvimento e em tempo de execução.

A publicação do consumidor e dos provedores de serviços permitem que suas informações sejam administradas através do registro ESB, suas relações e interações podem ser visualizadas e atualizadas.


\section{Habilidades Típicas de um ESB}


Segundo Falko Menge as habilidades que todo ESB deveria prover são:


\subsection{Invocação}

%--Nada de etc... dá sentido de incerteza. Incerteza em um texto científico é abertura para questionamentos.

É a habilidade de enviar requisições e receber respostas de serviços e recursos integrados. Os padrões de comunicação dos web-services devem ser suportados. Outros padrões de comunicações deveriam ser implementados também. Ex.: j2ee, jsm.

\glossary{name={Java Message Service (JMS)}, description={é uma API da linguagem Java para middleware  orientado à mensagens. Através da API JMS duas ou mais aplicações podem se comunicar por mensagens.}}
\glossary{name={Java EE (J2EE)}, description={Plataforma de programação para servidores na linguagem de programação Java.}}

\subsection{Roteamento}
É a habilidade de decidir o destinatário de uma mensagem durante seu transporte. Roteamento desacopla o código de uma mensagem dos seus destinatários finais. O padrão comum para o endereçamento é o URI, mas adicionalmente o {\it WS-Addressing} deveria ser implementado.

\subsection{Mediação}
Refere-se a todas as transformações e traduções entre recursos, incluindo protocolos de transporte e formato ou conteúdo de mensagens.

\subsection{Segurança}
Capacidade de:
\begin{itemize}
	\item Criptografar e desincriptografar conteúdos de mensagens;
	\item Autenticação;
	\item Controle de acesso.
\end{itemize}

\subsection{Gerenciamento}

Deve prover auditoria e registros históricos para monitorar a infraestrutura e cenário de integração. Inclusive possibilitando o controle de processos em execução.


\subsection{Orquestração}

Deve incluir ferramentas para execução de processos de negócios descritos em {\it Web Service Business Process Execution Language} (WS-BPEL).


\subsection{Exemplos de ESB}
Open Source:
\begin{itemize}
	\item Mule;
	\item JBoss – RedHat
\end{itemize}

Proprietários
\begin{itemize}
	\item BizTalk – Microsoft
	\item WebSphere – IBM
\end{itemize}


\chapter{Orquestração}


O padrão para orquestração de serviço é o {\it Web Service Business Process Execution Language }(WS-BPEL), que é uma linguagem executável para especificar interações entre serviços {\it WEB}. Essa linguagem permite que os processos sejam definidos de duas formas \cite{bpel}:

\begin{enumerate}
	\item Processo de negócio executável: o processo de negócio é especificado com todos os detalhes e isso permite que ele seja executado.
	\item Processo de negócio abstrato: é especificado apenas a troca de mensagens que ocorrerá entre as partes. Detalhes internos podem ser omitidos, porém o processo não será executável.
\end{enumerate}

BPEL é uma linguagem baseada em XML que suporta vários padrões de web services. Foi criada pela fusão de duas linguagens WSFL  e XLANG. WSFL foi criada pela IBM. XLANG foi desenvolvida pela Microsoft, ela é uma linguagem estruturada em blocos. BPEL combina as duas abordagens e prove um vocabulário rico para a descrição de processos de negócios.

Abaixo algumas primitivas permitidas pela linguagem:
\begin{itemize}
	\item {\it Invoke}: permite que um serviço seja invocado de forma síncrona ou assíncrona.
	\item {\it Sequence}: estabelece um grupo de atividades para serem executadas sequencialmente.
	\item {\it Flow}: estabelece um grupo de atividades para serem executadas paralelamente.
	\item {\it While}: define {\it loops}.
	\item {\it Switch}: para implementar condições. 
\end{itemize}

\chapter{BASS}


Business Application Support through Software Services (BASS) é um framework que oferece uma API que encapsula e esconde o conceito de serviço do resto da aplicação, suporta seleção e execução de serviço orientado pelas regras de negócio e reduz o esforço de desenvolvimento.\cite{bass}

A arquitetura do BASS é dividida em duas camadas principais, a de Integração e a do Aplicativo. A camada de integração é constituída de dois elementos distintos, BASS framework e os componentes de integração do lado cliente. BASS é independente de aspectos de implementação do lado cliente, na verdade ele foi feito para trabalhar com Web Service, mas funciona com qualquer outra tecnologia que siga os princípios de serviço.

Os stubs de serviço, presente no lado cliente, encapsulam os detalhes de invocação de serviços (URI do serviço, protocolo de rede, etc.) e dependem de uma API de acesso especifica, exemplo Apache Axis/Axis2.

O desenvolvimento da camada de aplicativo tem como objetivo suportar a lógica de negócio sem haver dependência com a camada de integração. Isto é alcançado colocando a API BASS entre as camadas de aplicação e os componentes de integração. A API BASS oferece um grupo de operações chamados RLSDU (Retrieve, List, Save, Delete e Update).

RLSDU é um conjunto de operações similares ao CRUD. Elas agem sobre entidades de negócios envolvidas nas colaborações de negócios.

\glossary{name={CRUD}, description={ o acrônimo da expressão em língua Inglesa Create, Retrieve, Update e Delete, usada para definir quatro operações básicas usadas em bancos de dados relacionais (RDBMS) ou em interface para usuários para criação, consulta, atualização e destruição de dados.}}

\begin{itemize}
	\item {\it Retrieve}: retorna o estado externo da entidade de negócios. Este estado externo é retornado e convertido em uma instancia de uma entidade de negócio.
	\item {\it List}: retorna o estado externo de um grupo de instancias de entidades de negócios.
	\item {\it Save}: salva o estado de uma instancia de entidade de negócio em uma representação externa. A representação é criada se ela não existir.
	\item {\it Delete}: Remove a representação de um estado externo associadas a uma instancia de entidade de negócio.
	\item {\it Update}: Atualiza o estado de uma instancia de entidade de negocio existente baseado no estado de sua representação externa. 
\end{itemize}

A lógica de negocio do aplicativo relativa a integração é desenvolvida em termos das operações RLSDU e entidades de negócio. Quando uma operação RLSDU é executada, o Web Service necessário para a realização da operação é dinamicamente identificado, mapeado e executado.

Cada entidade de negócio ou operação RLSDU é customizado de maneira que estabeleça uma correspondência correta entre a entidade de negócio e os serviços para realizar a ação. Essa correspondência é estabelecida associando service bindings com entidades de negócios e operações RLSDU. Binding definem stubs de serviços, tipos de dados, operações, e parâmetros necessários para invocar um serviço especifico.


\chapter{Infra-estrutura tecnologica da SPTC/PC-ES}

\glossary{name={SPTC}, description={Superintendência da Polícia Técnico-Científica}}

A SPTC possuí uma equipe técnica voltada para a Tecnologia de Informação (TI). Essa equipe é responsável pela manutenção da infra-estrutura de comunicação, isto é, a rede interna da instituição. Sendo essa sua principal responsabilidade. Contudo, também há na equipe uma divisão responsável pelo desenvolvimento de sistemas que auxiliem os processos de negócio executados na secretária. No momento, há sistemas de apoio para os processos de:
\begin{itemize}

	\item Identificação de indivíduos;
	\item Identificação criminal;
	\item Gerência de documentos;
\item Emissão de laudos voltados para o Departamento Médico Legal (DML) (em implantação);
	\item Controle de acesso as aplicações.
\end{itemize}


Há ainda outros sistemas implantados em alguns departamentos específicos da SPTC. Por exemplo o  sistema que auxilia os processos realizados pelo Departamento de Identificação (DEI). Nesse departamento os sistemas utilizados como apoio aos processos de negócio foram implantados e são mantidos de forma independente do setor de TI da polícia civil. 


Um dos sistemas foi implantado pela Secretaria de Segurança Pública do Espírito Santo (SESPE) e é o responsável pelo registro das informações de identificação civil no estado. Outro sistema utilizado no processo está relacionado a transferencia de informações entre a SPTC e a Polícia Federal (PF). De forma a viabilizar essa transferência de informações a Polícia Federal forneceu à secretária uma estação de trabalho especifica a essa tarefa capaz de consultar as informações referentes ao registro criminal federal e registrar novas informações nessa base.  Essa estação conta com a instalação do sistema baseado em AFIS utilizado pela polícia federal.



A principal funcionalidade dos sistemas mantidos pela equipe de TI é registrar informações especificas a cada um dos departamentos que compõem a SPTC e gerar como saída laudos e relatórios sobre essas informações. Outros sistemas voltados para trabalhos periciais foram implantados, como por exemplo o sistema baseado em AFIS fornecido pela PF,  esses sistemas, por serem voltados a tarefas específicas são comprados de fornecedores externos e implantados pontualmente nos setores que os necessitam e ficam fora do escopo da equipe de TI da instituição. 



Apesar de auxiliarem individualmente cada setor as aplicações desenvolvidas e implantadas na SPTC não foram desenvolvidas visando a integração de informações. Dessa maneira, é possível existir duplicação de informações, dificuldade na obtenção de informações e re-trabalho das equipes de cada departamento. A falta de integração entre esses sistemas resulta em dificuldades e maiores custos para a formulação e apuração do inquérito policial.  

\chapter{Abordagens Relacionadas}

\section{e-PING}
A arquitetura e-PING (Padrões de Interoperabilidade de Governo Eletrônico) define um conjunto mínimo de premissas, políticas e especificações técnicas que regulamentam a utilização da Tecnologia de Informação e Comunicação (TIC) na interoperabilidade de Serviços de Governo Eletrônico, estabelecendo as condições de interação com os demais Poderes e esferas de governo e com a sociedade em geral.

As áreas cobertas pela e-PING estão segmentadas em:
\begin{itemize}
	\item Interconexão;
 	\item Segurança;
 	\item Meios de Acesso; 
	\item Organização e Intercâmbio de Informações; 
	\item Áreas de Integração para Governo Eletrônico.
\end{itemize}

Para cada um desses segmentos foram especificados componentes, que para quais são estabelecidos padrões. Estes padrões sempre que possíveis serão abertos, mas os proprietários também serão aceitos de forma transitórias, são substituídos assim que houver condições. Esses padrões são analisados e classificados em cinco níveis:

\begin{itemize}
	\item {\bf Adotado (A)}: item adotado pelo governo como padrão da arquitetura.
	\item {\bf Recomendado (R)}: item que atende às políticas técnicas da e-PING, é reconhecido como item que deve ser utilizado dentro das instituições do governo, mas ainda não foi submetido a um processo formal de homologação.
	\item {\bf Em Transição (T)}: item não recomendado, tendem a ser desativados por completo.
	\item {\bf Em Estudo (E)}: componente que está em avaliação e poderá ser adequado a um dos níveis acima.
	\item {\bf Estudo Futuro (F)}: componente que será objeto de estudos futuros.
\end{itemize}


A adesão do e-PING é voluntária aos cidadãos e às diversas instâncias de governo, dentro e fora do país. Porém, para os órgãos do governo federal – Poder Executivo brasileiro a adoção dos padrões e políticas contidos na e-PING é obrigatória. Isto inclui os órgãos da Administração Direta: Ministérios, Secretarias e outras entidades governamentais de mesma natureza jurídica, ligados direta ou indiretamente à Presidência da República do Brasil e as Autarquias e fundações.

\subsection{Segurança}

Para que um sistema esteja de acordo com os padrões de segurança do e-PING, ele deve atender as políticas técnicas e implementar os padrões aprovados.

\subsection{Políticas Técnicas}

Os dados, informações e sistemas de informação do governo devem ser protegidos contra ameaças de forma a reduzir riscos e garantir a integridade, confidencialidade, disponibilidade e autenticidade.


Os dados e informações devem ser mantidos com o mesmo nível de proteção, independentemente do meio em que estejam sendo processados, armazenados ou trafegando.


As informações sensíveis que trafegam em redes inseguras, incluindo as sem fio, devem ser criptografadas, de modo adequado, conforme os componentes de segurança especificados neste documento.


Os requisitos de segurança da informação, dos serviços e de infraestrutura devem ser identificados e tratados de acordo com a classificação da informação, níveis de serviço definidos e resultado da análise de riscos.


A segurança deve ser tratada de forma preventiva. Para os sistemas que apoiam processos críticos devem ser elaborados planos de continuidade, nos quais serão tratados os riscos residuais visando atender os níveis mínimos de produção.


A segurança é um processo que deve estar inserido em todas as etapas do ciclo de desenvolvimento de um sistema.


Os sistemas devem possuir registros históricos (logs) para permitir auditorias e provas materiais, sendo imprescindível a adoção de um sistema de sincronismo de tempo centralizado, bem como deve-se utilizar mecanismos que garantam a autenticidade dos registros armazenados, se possível com assinatura digital.


Os serviços de segurança de XML devem estar em conformidade com as especificações do W3C.


Nas redes sem fio metropolitanas recomenda-se a adoção de valores randômicos nas associações de segurança, diferentes identificadores para cada serviço e a limitação do tempo de vida das chaves de autorização.


O uso de criptografia e certificação digital, para a proteção do tráfego, armazenamento de dados, controle de acesso, assinatura digital e assinatura de código, deve estar em conformidade com as regras da ICP-Brasil.


A documentação dos sistemas, dos controles de segurança e das topologias dos ambientes deve ser mantida atualizada e protegida, mantendo-se grau de sigilo compatível.
- Os usuários devem conhecer suas responsabilidades com relação à segurança e devem estar capacitados para a realização de suas tarefas e utilização correta dos meios de acesso.


Os Órgãos da APF, visando a melhoria da segurança, devem ter como referência as normas NBR ISO/IEC 27002:2005 – código de prática para a gestão da segurança da informação; NBR ISO/IEC 27001:2006 – sistemas de gestão de segurança da informação; NBR 15999-1:2007 e 15999-2:2008 – gestão de continuidade de negócios; NBR ISO/IEC 27005:2008 – gestão de riscos de segurança da informação; Instrução Normativa no 01/2000, Norma Complementar no 02/2009, 04/2009 e 05/2009.


Para especificações sobre cartões inteligentes e tokens, deverão ser adotados os requisitos contidos nos normativos que tratam da homologação de equipamentos e sistemas no âmbito da Infraestrutura de Chaves Públicas Brasileira – ICP-Brasil (http://www.icpbrasil.gov.br/). Estes requisitos, observados por produtos homologados na ICP-Brasil, tais como mídias que armazenam os certificados digitais e respectivas leitoras, além dos sistemas e equipamentos necessários à realização da certificação digital, estabelecem padrões e especificações técnicas mínimas, a fim de garantir a sua interoperabilidade e a confiabilidade dos recursos de segurança da informação por eles utilizados. Importante observar que os dados armazenados em um determinado cartão inteligente ou token não poderão estar protegidos por qualquer tipo de licenciamento que proíba a sua leitura por qualquer outro software que não o do fornecedor daquele cartão inteligente ou token.

\subsection{Padrões Aprovados}
\begin{comment}
Exemplo de tabela

\begin{table}[!th] 
	\begin{tabular}{|l|c|r|} 
	\hline 
	first & row & data \\ 
	second & row & data \\ 
	\hline \end{tabular} 
\caption{This is the caption} 
\label{ex:table} 
\end{table}

\end{comment}

%%\begin{table}[h]
%%\begin{tabular}{|l|r|}
%\hline
{\bf Segurança de redes Ipv4}


IPSec Authentication Header RFC 4303 (http://www.ietf.org/rfc/rfc4303.txt) e RFC 4835 (http://www.ietf.org/rfc/rfc4835.txt) para autenticação de cabeçalho do IP.
IKE – Internet Key Exchange, RFC 4306 (http://www.ietf.org/rfc/rfc4306.txt), deve ser utilizado sempre que necessário para negociação da associação de segurança entre duas entidades para troca de material de chaveamento. ESP – Encapsulating Security Payload, RFC 4303 (http://www.ietf.org/rfc/rfc4303.txt) Requisito para VPN – Virtual Private Network. 

{\bf Segurança de redes Ipv4 para protocolos de aplicação.}


O S/MIME v3 ,RFC 2633 (http://www.ietf.org/rfc/rfc2633.txt) deverá ser utilizado quando for apropriado para segurança de mensagens gerais de governo.

{\bf Acesso a caixas postais.}


O acesso à caixa postal deverá ocorrer através do cliente do software de correio eletrônico utilizado, considerando as facilidades de segurança nativas do cliente. Quando não for possível utilizar o cliente específico ou for necessário acessar a caixa postal através de redes não seguras (por exemplo: Internet) deve-se utilizar HTTPS de acordo com os padrões de segurança de transporte descritos na RFC 2595 (http://www.ietf.org/rfc/rfc2595.txt), que trata da utilização do TLS com IMAP, POP3 e ACAP.

{\bf Conteúdo de e-mail.}


O S/MIME V3 deverá ser utilizado quando for apropriado para segurança de mensagens gerais de governo. Isso inclui RFC 3369 (http://www.ietf.org/rfc/rfc3369.txt), RFC 3370 (http://www.ietf.org/rfc/rfc3370.txt),
RFC 2631 (http://www.ietf.org/rfc/rfc2631.txt), RFC 3850 (http://www.ietf.org/rfc/rfc3850.txt), 
RFC 3851 (http://www.ietf.org/rfc/rfc3851.txt) e RFC 3852 (http://www.ietf.org/rfc/rfc3852.txt).

{\bf Assinatura.}


Utilizar certificado padrão ICP-Brasil para assinatura de e-mail, quando exigido. Em conformidade com o disposto na Medida Provisória no 2.200-2, de 24/08/2001 e Decreto no 3.996 de 31/10/2001.

{\bf Algoritmo para transporte de chave criptográfica de conteúdo/sessão}

RSA 

{\bf Algoritmos criptográficos baseados em curvas elípticas.}


ECDSA 256 e ECDSA 512 (rfc 5480 – http://www.ietf.org/rfc/rfc5480.txt). ECIES 256 e ECIES 512 (Resolução no 65, de 09/06/2009, do Comitê Gestor da Infra-estrutura de Chaves Públicas Brasileira – ICP-Brasil).

{\bf Assinaturas XML.}


Sintaxe e Processamento de assinatura XML (XMLsig) conforme definido pelo W3C http://www.w3.org/TR/xmldsig-core/.

{\bf Navegadores.}


Somente utilizar testemunhas de conexão de caráter permanente (cookies) com a concordância do usuário. Resolução n. 7 do Comitê Executivo do Governo Eletrônico (Capítulo II, Art.7o). Informática Forense Guide to Integrating Forensic Techniques into Incident Response – NIST - Special Publication 800- 86 - (http://csrc.nist.gov/publications/nistpubs/800- 86/SP800-86.pdf).
%\hline
%\end{tabular}
%\caption{Padrões definidos pelo padrão e-PING.}
%\end{table}


\chapter{Proposta}

\chapter{Conclusão}


Organizações típicas estão sempre adquirindo e desenvolvendo novas aplicações ou mesmo fazendo parcerias com outras empresas que possuem sistemas completamente diferentes. Para que uma organização caminhe todos esses sistemas precisam cooperar. Então é preciso um mecanismo flexível para realizar todas essas integrações.



Um mecanismo cada vez mais popular para obter toda essa flexibilidade de integração é a arquitetura orientada a serviços. Em conjunto com um enterprise service bus o SOA pode ser mais facilmente implementado, pois um ESB possui funcionalidades que o SOA deve ter, como roteamento, mediação, orquestração e gerenciamento de serviços.



Muitas vezes um serviço simples não é o suficiente para cumprir uma tarefa, é preciso que vários serviços cooperem juntos para cumpri-la. Uma forma de fazer isso é usando orquestração com a linguagem BPEL. Com ela é possível modelar um processo de negócios complexos e dependendo do nível de detalhes este processo poderá ser executado como qualquer outro serviço web.

\printglossary

\bibliography{referencias}
\bibliographystyle{plain}

\end{document}
